@samsonasik I've made some improvements to your test and all seems to be working fine - on travis and on local. Please have a look.

Tests in that file run in separate process so there is no need for clear the session at the end of the test.

@michalbundyra thank you, that's ok 👍

@michalbundyra any chance for merging ? thank you.

@Xerkus I've removed session_write_close() function call

This is not a bugfix, but rather improvement that changes behavior. Should target next minor.

So far these are the only effect of this change that I can think of:

1. Refreshed session id is lost on bad connection (like mobile network). Session data is effectively lost as previous session is deleted.
   Example:

   • User comes as a guest
   • Multiple items are placed into the cart
   • On checkout user logs in, session id is regenerated
   • Request fails to load, new session id is lost
   • Cart reference in session is lost. No recovery available.

   Generally we see this as an acceptable very low probability security tradeoff.

2. With session.use_strict_mode enabled, deleting session might have client side parallel request race condition leading to scenario 1. Strict mode is off by default.
   Example:

   • Browser launches request that will regenerate session id.
   • Browsers launches additional parallel requests with original session id. Those requests are waiting on blocking session_start()
   • Browser receives response with regenerated session id
   • Waiting parallel request proceed once session lock is released by first request. Since session was deleted strict mode kicks in and regenerates session id.
   • With SAPI emitter session cookie is automatically sent (This should probably be investigated in laminas/laminas-httphandlerrunner - reset php queued headers before emitting PSR response)
   • Browser receives parallel response and overwrites proper regenerated session id
   • We got scenario 1.

   I did not try to recreate this scenario.
   If it is an actual issue when strict mode is enabled we can replace session data instead of deleting with say ['__deleted__' => true] . Needs further investigation.

Why was it done in a way explicitly preserving old session with data? session_regenerate_id(true) could have been used otherwise to achieve what this PR wants to introduce.

We chose not to use session_regenerate_id() because we needed to be able to call session_start() with custom options (use_cookies, use_only_cookies, and cache_limiter). Unfortunately, when you call session_regenerate_id, PHP sets the set-cookie header itself, preventing us from setting the options; this meant having custom logic when regenerating the cookie.

As such, the approach here by @samsonasik is the correct one.

@michalbundyra merge-able ?

@samsonasik Yes, I'll merge it soon, it's on my list, but first I am working on laminas-form.

Thanks, @samsonasik!